Hello @bencoveney
Is it possible to review this PR please ?

Hi @Romakita

Thanks for the contribution 👍 The code changes (syntax, tests) all look good to me.

We have had some discussion previously about esm support - see:

• Feature: Add Extension Option to Support Custom Suffixes (useful for ESM builds) #174 - This PR proposed changes similar to yours, which we ended up not merging.
• Support for ES modules #178 - This issue is where we made a plan for what ESM support will look like.

A couple of points:

• I haven't read up on the latest developments in supporting ESM, but IIRC always adding a .js suffix to imports doesn't work for all ESM use cases - and we would need to do something closer to whats described in Support for ES modules #178 to have a complete solution.
• TypeScript's esm support is still experimental, so we might want to be a bit careful about how we support it at the moment https://www.typescriptlang.org/docs/handbook/esm-node.html

I've reopened #178 for discussion - I think it would be great to get a plan agreed there before we merge anything.

For anything like this where we add new options that people will then add to their config files, it will create a maintenance cost in the future (and cause us some pain if we get it wrong) so hopefully it makes sense to be a bit careful and plan that feature correctly.

Hello @bencoveney
thanks for your comment :)

I understand your point. we can rename the option --esm by --experimental-esm? in this case, there will be no strong commitment on your part and that brings you feedback from the community.

EDIT: Ok I see the new options --input-type. But it's more complex than I expected. You trying to detect the type of the module commonjs/module.

I haven't read up on the latest developments in supporting ESM, but IIRC always adding a .js suffix to imports doesn't work for all ESM use cases - and we would need to do something closer to whats described in #178 to have a complete solution.

In fact, your tool always import .js file to create barrel file, right ?

Today, I propose your awesome tool for any project based on the Ts.ED framework. But, the problem is around the ESM support, because your tool doesn't provide a way to generate barrels with extension, I could not keep Barreslby in the stack in the short term. And as the module works very well, I wanted to advance the subject with you rather than doing a fork.

You trying to detect the type of the module commonjs/module.

Sort of yes. My understanding at the moment is: it would be best to match the behaviour of the TypeScript compiler for determining whether a file should be treated as an ESM module, and that is roughly what the TypeScript compiler does: https://github.com/microsoft/TypeScript/blob/0ada54c006015bda2fd3b593607f58206168aa0b/src/compiler/program.ts#L845

I am open to working towards that solution incrementally - There's a note on #178 that proposes a halfway solution:

If --input-type is not provided, assume we are using CommonJS modules (until some point in the future if/when we can detect the module type automatically).
--input-type=commonjs will force Barrelsby to create CommonJS modules.
--input-type=module will force Barrelsby to create ES modules.

Would this work for your use case? I would prefer to take that route, instead of adding an experimental argument.

@BitForger interested if you have any thoughts on this, now that's popped up again.

@bencoveney I changed the option according to your latest comment.

But I see you working on a v3 so maybe this PR isn't longer needed :)

See you
Romain